|
|
|
|
|
|
|
pencil to avoid the mess of correcting pen-based writing on applications. There are six tellers total for each branch. By now, you're sweating a bit, and you roll up your sleeves. |
|
|
|
|
|
|
|
|
New Term: A domain, in this context, represents the set of business tasks and users affected by the solution you design and develop. |
|
|
|
|
|
|
|
|
The branch manager likes your diligence. She takes you aside and mentions that if you can develop an application for this branch within three months, she will make a recommendation to bank executives to deploy the application citywide. You ask her how she arrived at three months. It's a guess. We need it as soon as possible. Can you do it? You tell her that you'll need time to ask the tellers questions. Well, I don't have the luxury of having a teller answer too many questions. Can you just ask me? I know what they do. You agree, although you still want to question the hands-on tellers. |
|
|
|
|
|
|
|
|
Elaboration and Construction |
|
|
|
|
|
|
|
|
After you have decided that you understand what's at stake in solving a problem, you can begin to elaborate your knowledge into a solution. Solution development builds on the analysis activities you perform during the Inception Phase and is also known as the Elaboration and Construction Phases. During solution development, you elaborate through analysis and design in an iterative and incremental manner. This means that any discoveries about the context of the problem will cause you to loop through the artifacts of your knowledge and update them. You will identify additional use cases, create and revise analysis and design models, and re-interview customers. After you have iterated through analysis and design to the point where new discoveries are trivial, you can begin Construction. The Construction Phase is that point in the project when you develop the actual Visual Basic code, using the design models you created. The project plan is based on the activities necessary for solution development. |
|
|
|
|
|
|
|
|
Tip
In many industries, especially the telecommunications and engineering industries, business terminology is often vague or conflicting. Terms are confusingly interchangeable. Confusing terminology is a major factor in the failure of a software development project. The nouns in use-case documentation identify candidate class types and business concepts. This terminology is one of the pillars of the proposed system's architecture. As part of your separation of concerns, you must find clear, distinct definitions of business terms so that your classes and components can be properly built. Without making this distinction, you will find it difficult to communicate with customers, new project personnel you hire, and even yourself, when you are thinking through a problem and solution. |
|
|
|
|
|
|